Product Code Database
An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by . The term email address in this article refers to just the addr-spec in Section 3.4 of . The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.
An email address, such as john.smith@example.com, is made up from a local-part, the symbol @, and a domain, which may be a domain name or an IP address enclosed in brackets. Although the standard requires the local-part to be case-sensitive, it also urges that receiving hosts deliver messages in a case-independent manner, e.g., that the mail system in the domain example.com treat John.Smith as equivalent to john.smith; some mail systems even treat them as equivalent to johnsmith. "...you can add or remove the dots from a mail address without changing the actual destination address; and they'll all go to your inbox...", Google.com Mail systems often limit the users' choice of name to a subset of the technically permitted characters; with the introduction of internationalized domain names, efforts are progressing to permit non-ASCII characters in email addresses.
Due to the ubiquity of email in today's world, email addresses are often used as regular usernames by many websites and services that provide a user profile or account. For example, if a user wants to log in to their Xbox Live video gaming profile, they would use their Microsoft account in the form of an email address as the username ID, even though the service in this case is not email.
The transmission of electronic mail from the author's computer and between mail hosts in the Internet uses the Simple Mail Transfer Protocol (SMTP), defined in , and extensions such as . The mailboxes may be accessed and managed by applications on personal computers, mobile devices or webmail sites, using the SMTP protocol and either the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP).
When transmitting email messages, mail user agents (MUAs) and mail transfer agents (MTAs) use the domain name system (DNS) to look up a Resource record (RR) for the recipient's domain. A mail exchanger resource record (MX record) contains the name of the recipient's mailserver. In absence of an MX record, an address record (A record or AAAA record) directly specifies the mail host.
The local-part of an email address has no significance for intermediate mail relay systems other than the final mailbox host. Email senders and intermediate relay systems must not assume it to be case-insensitive, since the final mailbox host may or may not treat it as such. A single mailbox may receive mail for multiple email addresses, if configured by the administrator. Conversely, a single email address may be the alias to a distribution list to many mailboxes. , electronic mailing lists, sub-addressing, and Email filtering addresses, the latter being mailboxes that receive messages regardless of the local-part, are common patterns for achieving a variety of delivery goals.
The addresses found in the header fields of an email message are not directly used by mail exchanges to deliver the message. An email message also contains a message envelope that contains the information for mail routing. While envelope and header addresses may be equal, Email spoofing addresses (also called spoofed email addresses) are often seen in email spam, phishing, and many other Internet-based scams. This has led to several initiatives that aim to make such forgeries of fraudulent emails easier to spot.
An email address also may have an associated "display-name" (Display Name) for the recipient, which precedes the address specification, surrounded by angled brackets in that case, for example: John Smith
Earlier forms of email addresses for other networks than the Internet included other notations, such as that required by X.400, and the UUCP bang path notation, in which the address was given in the form of a sequence of computers through which the message should be relayed. This was widely used for several years, but was superseded by the Internet standards promulgated by the Internet Engineering Task Force (IETF).
If unquoted, it may use any of these ASCII characters:
If quoted, it may contain Space, Horizontal Tab (HT), any ASCII graphic except Backslash and Quote and a quoted-pair consisting of a Backslash followed by HT, Space or any ASCII graphic; it may also be split between lines anywhere that HT or Space appears. In contrast to unquoted local-parts, the addresses ".John.Doe"@example.com, "John.Doe."@example.com and "John..Doe"@example.com are allowed.
The maximum total length of the local-part of an email address is 64 octets.
In addition to the above ASCII characters, international characters above U+007F, encoded as UTF-8, are permitted by RFC 6531 when the EHLO specifies SMTPUTF8, though even mail systems that support SMTPUTF8 and 8BITMIME may restrict what characters to use when assigning local-parts.
A local-part is either a Dot-string or a Quoted-string; it cannot be a combination. Quoted strings and characters, however, are not commonly used. RFC 5321 also warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form".
The local-part postmaster is treated specially—it is case-insensitive, and should be forwarded to the domain email administrator. Technically all other local-parts are case-sensitive, therefore johns@example.com and JohnS@example.com specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent. Indeed, RFC 5321 warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where ... the Local-part is case-sensitive".
Despite the wide range of special characters that are technically valid, organisations, mail services, mail servers, and mail clients in practice often do not accept all of them. For example, Windows Live Hotmail only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-).. However, the phrase is hidden, thus one has to either check the availability of an invalid ID, e.g., me#1, or resort to alternative displaying, e.g., no-style or source view, in order to read it. Common advice is to avoid using some special characters to avoid the risk of rejected emails.
According to RFC 5321 2.3.11 Mailbox and Address, "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server.
Interpretation of the local-part is dependent on the conventions and policies implemented in the mail server. For example, case sensitivity may distinguish mailboxes differing only in capitalization of characters of the local-part, although this is not very common. Are Email Addresses Case Sensitive? by Heinz Tschabitscher For example, Gmail ignores all dots in the local-part of user email address for the purposes of determining account identity.
Addresses of this form, using various separators between the base name and the tag, are supported by several email services, including Andrew Project (plus), Runbox (plus), Gmail (plus), Rackspace (plus), Yahoo! Mail Plus (hyphen), Apple's iCloud (plus), Outlook.com (plus), Mailfence (plus), Proton Mail (plus), Fastmail (plus and Subdomain Addressing), postale.io (plus), Pobox (plus), MeMail (plus), and MTAs like MMDF (equals), Qmail and Courier Mail Server (hyphen). Postfix and Exim allow configuring an arbitrary separator from the legal character set.
The text of the tag may be used to apply filtering, or to create single-use, or disposable email addresses.Gina Trapani (2005) "Instant disposable Gmail addresses"
Comments are allowed in the domain as well as in the local-part; for example, john.smith@(comment)example.com and john.smith@example.com(comment) are equivalent to john.smith@example.com.
specifies that certain domains, for example those intended for documentation and testing, should not be resolvable and that as a result mail addressed to mailboxes in them and their subdomains should be non-deliverable. Of note for email are ''example'', ''invalid'', ''example.com'', ''example.net'', and ''example.org''.
An email address is generally recognized as having two parts joined with an at-sign ( @), although the technical specifications detailed in RFC 822 and subsequent RFCs are more extensive.
Syntactically correct, verified email addresses do not guarantee that an email box exists. Thus many email servers use other techniques and check the mailbox existence against relevant systems such as the Domain Name System for the domain or using callback verification to check if the mailbox exists. Callback verification is an imperfect solution, as it may be disabled to avoid a directory harvest attack, or callbacks may be reported as spam and lead to listing on a DNSBL.
Several validation techniques may be utilized to validate a user email address. For example,
Some companies offer services to validate an email address, often using an application programming interface, but there is no guarantee that it will provide accurate results.
The IETF's EAI Working group published RFC 6530 "Overview and Framework for Internationalized Email" that enabled non-ASCII characters to be used in both the local-parts and domain of an email address. RFC 6530 provides for email based on the UTF-8 encoding, which permits the full repertoire of Unicode. RFC 6531 provides a mechanism for SMTP servers to negotiate transmission of the SMTPUTF8 content.
The basic EAI concepts involve exchanging mail in UTF-8. Though the original proposal included a downgrading mechanism for legacy systems, this has now been dropped. The local servers are responsible for the local-part of the address, whereas the domain would be restricted by the rules of internationalized domain names, though still transmitted in UTF-8. The mail server is also responsible for any mapping mechanism between the IMA form and any ASCII alias.
EAI enables users to have a localized address in a native language script or character set, as well as an ASCII form for communicating with legacy systems or for script-independent use. Applications that recognize internationalized domain names and mail addresses must have facilities to convert these representations.
Significant demand for such addresses is expected in China, Japan, Russia, and other markets that have large user bases in a non-Latin-based writing system.
For example, in addition to the .in top-level domain, the government of India in 2011 got approval for ".bharat", (from Bhārat Gaṇarājya), written in seven Brahmic scripts for use by Gujrati, Marathi, Bangali, Tamil, Telugu, Punjabi and Urdu speakers. Indian company XgenPlus.com claims to be the world's first EAI mailbox provider, and the Government of Rajasthan now supplies a free email account on domain राजस्थान.भारत for every citizen of the state. A leading media house Rajasthan Patrika launched their IDN domain पत्रिका.भारत with contactable email.
The example addresses below would not be handled by -based servers without an extension, but are permitted by the UTF8SMTP extension of . Servers compliant with this will be able to handle these:
|
|
